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I. STATUS OF CLAIMS 



Claims 1-41 are cancelled. Claims 42-65 are rejected. Claims 42-65 are appealed. 
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II. GROUNDS OF REJECTION TO BE REVIEWED ON APPEAL 

Claims 58 and 59 are rejected under 35 U.S.C. §101 because claimed invention is 
directed to non-statutory subject matter. This rejection was withdrawn in the Examiner's 
Answer. 

Claims 43-53 and 55-65 are rejected under 35 U.S.C. § 102(e) as being anticipated by 
U.S. Patent Publication No. 2007/0192410 to Liversidge et al. (hereinafter "Liversidge"). 

Claim 54 is rejected under 35 U.S.C. § 103(a) as being unpatentable over Liversidge in 
view of U.S. Patent Publication No. 2001/0016038 to Sammon et al. (hereinafter "Sammon"). 
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III. REPLY TO EXAMINER'S ANSWER 

As a preliminary matter Appellants note that the Examiner has withdrawn the rejection 
under 35 U.S. C. § 101. While Appellants do not acquiesce to the reasons stated by the Examiner 
in withdrawing this rejection and Appellants contend that the rejection was improper for the 
reasons stated in Appellants' responses to the Office Actions and in Appellants' Appeal Brief, 
Appellants' respectfully thank the Examiner for withdrawing this rejection. 

Appellants present herein arguments related to the statements made by the Examiner in 
the Examiner's Answer, dated December 24, 2008. Appellants submit that these statements are 
in error and therefore the Examiner's allegations are without merit. The errors are described 
below. 

Error #1: Appellants have argued that Liversidge does not disclose a conference code, 
which when presented to the conference server by a remote device, authorizes the remeote 
device to join the data conference. In response to this argument, the Examiner stated in his 
answer, "Therefore, as stated in %0100 of Liversidge, the StatusEvent message is used to notify 
the creator of a team that specific users are now part of the team which could be interpreted as 
being authorized to be in a team. " Examiner's Answer, page 10. 

Appellants submit that Examiner's interpretation merely stresses that the StatusEvent 
message may include a notification that authorized users are now part of the team. But, this 
interpretation says nothing about wether the StatusEvent message itself is used in authorizing the 
users to be part of the team. Clearly, if the StatusEvent message were to be equated to the 
conference code (as has been maintained by the Examiner in the Final Office Action, dated April 
3, 2008) recited in claims 49 and 50, then it would be necessary to show, inter alia, that the 
StatusEvent message when presented to a conference server by a remote device authorizes the 
remote device to join the data conference. Appellants, by way of arguments presented below, 
show that (i) StatusEvent message is not presented to a conference server by a remote device, 
and (ii) StatusEvent message does not authorize the remote device to join the data conference. 
Accordingly, equating the StatusEvent message to the conference code recited in claims 42 and 
50 is improper. 

As pointed out by Liversidge in ]j 0100 and the accompanying Figure 14, StatusEvent 
message — the alleged conference code — is presented by the VTE server to VTE client (A), 
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where VTE client (A) is the client that initiates the conference. See Figure 14, messages 236, 
238, 240, 272, and 282. But the claims require that the conference code, when presented to the 
conference server by the remote device, authorizes the remote device to join the conference. 
Therefore, if the Examiner's claim that StatusEvent message can be considered to be a 
conference code were true, then it would be necessary for Liversidge to teach that the 
StatusEvent message when presented to the VTE server by either VTE client (B) or VTE client 
(C) authorizes VTE clients (B) or (C) to join the data conference. But there is no such teaching 
in Liversidge. This is because all the communications between the VTE server and the VTE 
clients (B) or (C) that include the StatusEvent message are shown to be directed from the VTE 
server to the VTE clients, and not from the VTE clients to the VTE server. As a result, the 
question of VTE server authorizing the VTE clients (B) or (C) based on the StatusEvent message 
does not even arise because the StatusEvent message is never sent by the VTE clients (B) or (C) 
to the VTE server. Therefore, the StatusEvent message, despite being interpreted as notifying 
the creator of the team that specific users are now part of the team, cannot be equated to a 
conference code as required by claims 42 and 50. 

Error #2: In response to the same argument by Appellants, the Examiner further stated, 
"Furthermore, when the CreateTeam message is received by one of the servers, it then 
continues to communicate with other servers to create said team. These messages could be 
interpreted as different conference codes to authorize users to join a data conference team 
which is being set up by the servers in the network in response to the creator of the team 's 
request to set up a team of clients to participate in a function. " Examiner's Answer, page 10. 

Examiner purports that the messages shown generated by Liversidge following the 
generation of CreateTeam message by the VTE client (A), can be interpreted as conference 
codes. Appellants respectfully disagree. The Examiner is merely making a conclusory statement 
without specifically pointing out which messages in particular are conference codes and why. 
Only because Liversidge 's system generates messages that eventually result in forming a 
conference team does not imply that such messages can be equated to the conference code as 
required by claims 42 and 50. This is because Liversidge 's system does not meet at least one 
limitation of claims 42 and 50 "wherein said data conference code, when presented to said 
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conference server by said remote device, authorizes said remote device to join said data 
conference." 

Error #3: The Examiner further stated, "In other words, the DTMF is a sequence of 
numbers, or a "conference code", that acts like a "password" to authorize the clients that are 
invited to the conference to join in. " Examiner's Answer, page 10. 

The DTMF signal from the VTE client (C) to the conference bridge is a response by the 
individual at the VTE client (C) to options provided by a speech invitation announcement, and 
not a password. 

Paragraphs 0187-0188 lists the components of invitation announcement sent by the 
conference bridge to the VTE client (C) as shown below: 

"[0187] . . . The announcement informs the team member using 
VTE client (C) that he has been invited by the team member using 
VTE client (A) to participate in a multi-media communications 
session taking place between the team members using VTE clients 
(A) and (B). The conference bridge also announces the topic and 
message, if provided, and session type to the team member using 
VTE client (C) followed by a menu of options for responding to 
the invitation. 

[0188] As shown in FIG. 36a, the team member using VTE client 
(C) accepts the invitation to join the multi-media 
communications session by selecting an appropriate key from the 
voice communications device keypad, which transmits a dual-tone 
modulated frequency (DTMF) signal (or by speaking an 
appropriate voice command which is interpreted by speech 
recognition) to the conference bridge to inform the conference 
bridge that the invitation is accepted (step 1468)." 

Therefore, the individual using VTE client (C) merely responds by selecting an 
appropriate key form the keypad that was already specified to him/her by the menu of options 
announced in the speech invitation announcement. In other words, the VTE client (C) sends 
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back to the conference bridge a signal representing a digit/number where the digit/number was 
previously specified by the conference bridge itself. Therefore, the VTE client (C)'s response 
does not include a "password" as claimed by the Examiner. 

Even if it were assumed, arguendo, that the VTE client (C)'s response is a "password," 
such a password still cannot be equated to a conference code. This is at least because claims 42 
and 50 require that (i) the conference code be received by the endpoint initiating the conference 
from the conference server, and (ii) that the endpoint initiating the conference transmit to the 
remote device data representative of the conference code. 

In Liversidge, the DTMF signal representing the "key" selected by the VTE client (C), 
fails to meet these requirements. This is because the "key" is never received by the VTE client 
(A) — the endpoint initiating the conference code. The communication of the "key" is limited 
only between the VTE server, the conference bridge, and the VTE client (C) — the invitee. 
Consequently, (i) the "key" is not received by VTE client (A) form the VTE server, and (ii) the 
VTE client (A) does not transmit any data representative of the "key" to VTE client (C). But 
these were the requirements for a conference code as recited in claims 42 and 50. 

Therefore, Appellants submit that the DTMF sequence of Liversidge cannot be equated 
to a conference code, as required by claims 42 and 50. 

Error #4: The Examiner further stated, "As seen in f 0186, the client is contacted and 
multiple numbers are sent to client C, Le., dialed number of the team member and a dialed 
number of the conference bridge, which is used by the client C to access the bridge and act as 
an authentication for communicating with the team...)." Examiner's Answer, page 11. 

Multiple numbers are not sent to client C, as claimed by the Examiner. Instead these 
numbers are sent from the VTE server to the virtual switching point (VSP). Relevant portion of 
paragraph 0186 is reproduced below: 

Consequently, the VTE server sends (step 1452) a MakeCall 
message to the VSP. The MakeCall message includes the dialed 
number of the team member using VTE client (C) as well as the 
dialed number of the conference bridge. (Emphasis added). 
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Therefore, Liversidge teaches that the dialed number of the team member and the dialed 
number of the conference bridge is sent by the VTE server to the VSP — there is no teaching of 
these numbers being sent to VTE client (C). This is further evident from Figure 36 of 
Liversidge, where "MakeCall(C(DN)CB(DN))" message (1452) is sent by the VTE server to the 
VSP. Therefore, Examiner's claim that multiple numbers are sent to VTE client (C) is improper. 

Error #5: The Examiner further stated, "Appellant is asked to view f 0186, which 
states that a dialed number of the conference bridge is communicated to the client. This 
could leave one to believe that a dialed number that is communicated to the client could be 
in a DTMF signal since the network which the devices are in is a PSTN and that the dialed 
number is also used when the client attempts to contact the server as stated in paragraph 
0188, as a DTMF signal " Examiner's Answer, page 12. 

First, as discussed previously, the dialed number of the conference bridge is never 
communicated to the VTE client (C) of Liversidge. On the contrary, ]j 0186 of Leversidge 
teaches that the conference bridge number is communicated by the VTE server to the VSP using 
MakeCall message (See Figure 36, MakeCall message 1452). Second, in 0186-0188, VTE 
client (C) never attempts to contact the server, as claimed by the Examiner. On the contrary, it is 
the VTE server that contacts VTE client (C) via a conference bridge. For example, U 0187 
teaches VTE server sends a Playlnvitation message through the data packet network to the 
conference bridge instructing the conference bridge to play an Invitation message announcement 
to the team member using VTE client (C). Therefore, VTE client (C) merely responds to an 
incoming call, and does not dial out to the VTE server. 

Therefore, Examiner's claim that the dialed number of the conference bridge is 
communicated to the VTE client and that the VTE client uses this number to contact the VTE 
server is improper. 

Respectfully submitted, 
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IV. CLAIMS APPENDIX 

1-41 (canceled without prejudice) 

42. (previously presented) A conference endpoint comprising: 
a CPU; 

a telephone line interface for coupling said conference endpoint to a telephone 
line; 

a network interface for coupling said conference endpoint to a computer network; 

a microphone for generating near speech signals for transmission over said 
telephone line, said near speech signals being representative of speech of a 
near conference participant; 

a speaker for converting to sound remote speech signals received from a remote 
device over said telephone line, said remote speech signals being 
representative of speech of at least one remote conference participant; 

a data conference initiation module, coupled to said network interface and to said 
telephone line interface for transmitting a data conference initiation request to 
a conference server over said computer network, for receiving a data 
conference code generated by said conference server, wherein said data 
conference code, when presented to said conference server by said remote 
device, authorizes said remote device to join said data conference, and for 
responsively transmitting over said telephone line a data conference 
invitation to said remote device, said conference invitation including 
information representative of said data conference code; and 

a memory for storing one or more files containing conference data distributed by 
said conference server via said computer network during a data conference, 

wherein said CPU is coupled to said telephone line interface, said network 
interface, said data conference initiation module, and said memory. 

43. (previously presented) The conference endpoint of claim 42, wherein said data 
conference initiation module transmits said conference initiation request in response to a 
predetermined user input. 
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44. (previously presented) The conference endpoint of claim 42, further comprising a 
display device coupled to said network interface for displaying said conference data. 

45. (previously presented) The conference endpoint of claim 42, wherein said 
conference data comprises video information. 

46. (previously presented) The conference endpoint of claim 42, wherein the data 
conference initiation module is further configured to transmit a conference join request to said 
conference server over said computer network responsive to a received conference invitation. 

47. (previously presented) The conference endpoint of claim 42, wherein said 
conference invitation comprises a string of Dual Tone Multi-Frequency (DTMF) tones. 

48. (previously presented) The conference endpoint of claim 42, further comprising a 
web browser for displaying said conference data, wherein said conference data comprises text 
and graphical information. 

49. (previously presented) The conference endpoint of claim 42, wherein said data 
conference initiation module is further configured for transmitting over said computer network a 
data conference invitation to said remote device. 

50. (previously presented) A method for initiating and managing a data conference 
from a near conference endpoint, comprising: 

at the near conference endpoint: 

establishing a connection over a telephone line with at least one remote 

conference endpoint; 
transmitting a data conference initiation request to a conference server over a 

computer network; 

receiving from the conference server a unique data conference code 
corresponding to said data conference initiation request, wherein said data 
conference code, when presented to said conference server, authorizes said at 
least one remote conference endpoint to join said data conference; 

generating an audio signal representative of said data conference code; 

transmitting said audio signal to said at least one remote conference endpoint over 
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said telephone network; and 
receiving one or more files containing conference data distributed by said 
conference server via said computer network during said data conference. 

5 1 . (previously presented) The method of claim 50, wherein the act of generating an 
audio code comprises generating a string of DTMF tones. 

52. (previously presented) The method of claim 50, wherein the act of transmitting a 
data conference initiation request is performed in response to a predetermined user input. 

53. (previously presented) A method for initiating and managing a data conference at 
a conference server, the method comprising the acts of: 

at said conference server: 

receiving a conference initiation request from a first conference endpoint over a 
computer network; 

generating a conference code in response to said conference initiation request, 

wherein said conference code when presented to said conference server by 

one or more second conference endpoints authorizes said one or more second 

conference endpoints to join said data conference; 
transmitting said conference code to said first conference endpoint over the 

computer network; 
maintaining a list of data conference participants based on received data 

conference join requests from said first and said one or more second 

conference endpoints; and 
distributing one or more files comprising conference data to said data conference 

participants over said computer network. 

54. (previously presented) The method of claim 53, wherein the act of distributing 
one or more files comprising conference data comprises transmitting a web page. 

55. (previously presented) The method of claim 53, wherein said conference data is 
representative of a document. 
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56. (previously presented) The method of claim 53, wherein said conference data is 
representative of a presentation slide. 

57. (previously presented) The method of claim 53, further comprising the act of 
converting at least one of said one or more files from a first format to a second format. 

58. (previously presented) A machine readable medium having embodied thereon a 
program, the program being executable by a machine to perform method acts for coordinating a 
data conference utilizing electronic means, the method acts comprising: 

at a near conference endpoint: 

transmitting a data conference initiation request to a conference server over a 
computer network; 

receiving a conference code from said conference server over said computer 
network in response to said data conference initiation request, wherein said 
conference code, when presented to said conference server by at least one 
remote conference endpoint, authorizes said at least one remote conference 
endpoint to join said data conference; 

generating an audio signal representative of said conference code; 

transmitting said audio signal to said at least one remote conference endpoint over 
a telephone line; and 

transmitting one or more files comprising conference data to said conference 

server for distribution to said at least one remote conference endpoint via said 
computer network during said data conference. 
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59. (previously presented) A machine readable medium having embodied thereon a 
program, the program being executable by a machine to perform method acts for coordinating a 
data conference utilizing electronic means, the method acts comprising: 

at a remote conference endpoint: 

receiving an audio signal representative of a conference code from at least one 
conference endpoint over a telephone line wherein said conference code, 
when presented to a conference server by said remote conference endpoint, 
authorizes said remote conference endpoint to join said data conference; 

transmitting a data conference join request including said conference code to said 
conference server over a computer network in response to receiving said 
audio signal; and 

receiving one or more files comprising conference data distributed by said 
conference server via said computer network during said data conference. 

60. (previously presented) A conference endpoint comprising: 
a CPU; 

a telephone line interface for coupling said conference endpoint to a telephone 
line; 

a network interface for coupling said conference endpoint to a computer network; 
a microphone for generating near speech signals for transmission over said 

telephone line, the near speech signals being representative of speech of a 

near conference participant; 
a speaker for converting to sound remote speech signals received from a remote 

device over said telephone line, the remote speech signals being 

representative of speech of at least one remote conference participant; 
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a data conference initiation module coupled to said network interface and to said 
telephone line interface and configured to receive over said telephone line 
interface from a remote conference endpoint a data conference invitation 
including information representative of a data conference code, wherein said 
data conference code, when presented to a conference server by said 
endpoint, authorizes said endpoint to join said data conference, and further 
configured to transmit a data conference join request including said data 
conference code to said conference server over said computer network in 
response to the received conference invitation; and 

a memory for storing one or more files containing conference data distributed by 
said conference server via said computer network during a data conference, 

wherein said CPU is coupled to said telephone line interface, said network 
interface, said data conference initiation module, and said memory. 

61 . (previously presented) The conference endpoint of claim 60, further comprising a 
display device coupled to said network interface for displaying said conference data. 

62. (previously presented) The conference endpoint of claim 60, wherein said 
conference data comprises video information. 

63. (previously presented) The conference endpoint of claim 60, wherein said data 
conference invitation comprises a string of dual tone multi-frequency (DTMF) tones. 

64. (previously presented) The conference endpoint of claim 60, further comprising a 
web browser for displaying said conference data, wherein said conference data comprises text 
and graphical information. 

65. (previously presented) The conference endpoint of claim 60, wherein said data 
conference initiation module is further configured for receiving over said computer network a 
data conference invitation from said remote conference endpoint. 
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